The invention relates to iterative decoding.
Present day storage systems employ a number of different techniques to eliminate errors that may occur during a data readback process. Every block that is read is decoded “on-the-fly” in a single read attempt, after some number of rereads or during a data recovery procedure. Typically, the “on-the-fly” decoding and the rereads are performed by a hardware decoder. When a reread operation is performed, the operating conditions are varied slightly, for example, by offsetting the transducer from the center of the track, to obtain a slightly different waveform. The reread operations repeat until the erroneous data are corrected or a predetermined number of reread operations has been performed, at which point the reread process may be terminated and a firmware-implemented data recovery procedure takes over.
It is possible to perform rereads and data recovery procedures to improve performance as long as the throughput of the storage system is not unacceptably degraded. Preferably, for example, a storage system is designed to ensure that reread and data recovery procedures do not slow the throughput by more than a predetermined throughput specification, e.g., 0.5%. Additionally, the system can ensure compliance with a reliability specification, for example, a reliability specification of 10−12, which specifies that no more than one block out of 1012 blocks read should fail to return correct data after a prescribed number of rereads and data recovery procedures are exercised. At present there are very clear boundaries between the “on-the-fly”, reread and firmware-implemented data recovery modes. What matters most, however, is that the two fundamental specifications of throughput and reliability, are satisfied.
Iterative decoding is a class of powerful detector/decoder architectures in which the detector provides symbol reliability values to the decoder and the decoder in turn provides reliability values back to the detector. These architectures are called “iterative” since the detector and decoder may update each other multiple times until the decoding process converges to the correct data. One example of such an iterative system applies the so-called Low Density Parity Check (LDPC) code. When many iterations between the detector and decoder are allowed, it is possible to achieve a significant performance gain (e.g., approximately 3 dBs for 100 iterations) relative to other architectures such as the Reed-Solomon (RS) decoders. Unfortunately, implementing just a single iteration in hardware is a major challenge in terms of hardware complexity, and implementing many more iterations can be extremely costly. On the other hand, when only a few iterations in hardware are allowed, much of the performance improvement is lost, e.g., a 3 dB gain for 100 iterations may be reduced to a single dB for as few as two iterations.
Typically, in prior RS approaches, a fixed lower level of redundancy decoding is used in the “on-the-fly” mode while a full redundancy decoding is used in the firmware-implemented data recovery mode in order to reduce complexity in the hardware. Thus, the error correction coding (ECC) power included in the on-the-fly decoder is less than full power, typically just enough to satisfy the throughput specification. The reliability specification is satisfied by using the full ECC power in firmware in addition to the rereads.
Such an approach for iterative decoders is problematic. As discussed earlier, the hardware implementation of an iterative decoder becomes extremely complex and costly since the capability to perform multiple iterations requires the duplication of the detector and decoder blocks many times over. Moreover, since iterative decoders are massively parallel and complex blocks, a firmware implementation is extremely time consuming.